The present disclosure relates generally to data transmission protocols in mobile communication systems and, more specifically, to systems and methods for controlling mobile stations (MSs) configured to implement extended uplink temporary block flows (EXT_TBF) and dynamic timeslot reduction (DTR).
As used herein, the terms MS, “user agent,” and “user equipment” (UE) can refer to electronic devices such as mobile telephones, personal digital assistants (PDAs), handheld or laptop computers, and similar devices that have network communications capabilities. In some configurations, MS may refer to a mobile, wireless device. The terms may also refer to devices that have similar capabilities but that are not readily transportable, such as desktop computers, set-top boxes, or network nodes.
An MS may operate in a wireless communication network that provides for data communications. For example, the MS may operate in accordance with Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS) technologies. Today, such an MS may further operate in accordance with Enhanced Data rates for GSM Evolution (EDGE), Enhanced GPRS (EGPRS), Enhanced GPRS Phase 2 (EGPRS2), or GSM EDGE Radio Access Network (GERAN).
To communicate with a network, an MS is configured to use a medium access control (MAC) protocol to determine the uplink (UL) and/or downlink (DL) communication resources available for use by the MS. GPRS, for example, uses a timeslot structure similar to that of GSM, but where timeslots can be dynamically allocated to MSs for both uplink and downlink transmissions. To communicate with a GPRS network, therefore, an MS may be configured to have a multi-slot capability that enables the MS to use between one (1) and eight (8) timeslots per carrier for data transfer between the MS and network. Because uplink and downlink channels are reserved separately, various multi-slot resource configurations may be assigned in different directions in different communications networks.
An MS may be allocated timeslots on dual carriers. A dual carrier ‘assignment’ comprises a set of timeslots assigned on the two carriers. In the case of an uplink dual carrier assignment, the assignment includes the total set of timeslots on both carriers that may be used by the MS for uplink transmissions; in the case of a downlink dual carrier assignment, the assignment is the total set of timeslots on both carriers upon which the network may send data to the MS.
For any given radio block period, the network dynamically allocates resources and determines upon which downlink timeslots or uplink timeslots the MS may receive and/or transmit data. In basic transmission time intervals (BTTI), a given radio block period can include 4 time division multiple access (TDMA) frames with each TDMA frame including 8 timeslots. The allocation algorithm may be implementation dependent, but may take account of the MS's multislot class (the maximum number of timeslots on which the MS can transmit or receive, and the time required to switch from transmit to receive and vice versa), and may take account of the amount of data the network (e.g., a base station controller (BSC)) or other network component expects the MS to receive or transmit).
In some cases, reduced transmission time intervals (RTTI) are used to communication with an MS. RTTI are a modification to the above structure where, instead of a radio block being transmitted as four bursts with each block being sent in a particular timeslot over four TDMA frames, a radio block (containing essentially the same amount of information) is transmitted using two timeslots in two TDMA frames. This reduces the transmission time for a block and reduces the overall latency of the system. Accordingly, a “reduced radio block period” can be 2 TDMA frames (approximately 10 ms) compared with a basic radio block period, which can be 4 TDMA frames (approximately 20 ms).
In a network, uplink allocations can be signaled to an MS using an uplink state flag (USF), which is a number between 0 and 7 (inclusive) that is signaled in downlink radio blocks. As part of the MS's uplink assignment, the MS is informed of which USF(s) on which timeslot(s) indicate an uplink allocation for that MS. USFs are generally included in the headers of downlink blocks. In the case of RTTI, USFs may be coded across radio blocks across four TDMA frames, for example, in the same manner as downlink BTTI radio blocks are sent (e.g., “BTTI USF mode”) or (using two timeslots) across two TDMA frames (e.g., “RTTI USF mode”).
In some communication standards, there are “m” timeslots assigned for reception and “n” timeslots assigned for transmission. Thus, for a multislot class type 1 MS, there may be Min(m,n,2) reception and transmission timeslots with the same timeslot number. For a multislot class type 2 MS, there may be Min(m,n) reception and transmission timeslots with the same timeslot number. In the case of downlink dual carrier configurations, if timeslots with the same timeslot number are assigned on both channels, in calculating the value of m they may be counted as one timeslot. As a result, where both downlink and uplink timeslots are assigned, if assigned a single timeslot in one direction and one or more timeslots in the opposite direction, the timeslot number of the first timeslot may be the same as one of the timeslot(s) in the opposite direction. Similarly, if assigned two or more uplink timeslots and two or more downlink timeslots, at least two of the uplink and downlink timeslots may have a common timeslot number. As a result, in uplink+downlink assignments, the timeslots that may be monitored for USFs and downlink data blocks may be largely co-incident. In some networks, assignments and allocations are essentially under the control of the network (for example, the BSC).
During an ongoing packet data session, for example, an MS with an assigned downlink TBF (temporary block flow) can be required to monitor all downlink timeslots in the MS's assignment in case the network sends the MS data in any of the allocated downlink timeslots. Similarly, if an MS has an assigned uplink TBF, the MS may be required to monitor all timeslots on which the USF (uplink state flag) could be sent to dynamically allocate uplink resources. If an MS has both uplink and downlink TBFs, therefore, the MS must monitor as many relevant downlink timeslots as possible, taking into account any allocated uplink transmissions opportunities.
In the case that either the network or the MS has no data to send (or only a small amount of data to send), and particularly when neither the network nor the MS has data to transmit, this monitoring activity results in significant wasted battery power in the MS. To minimize battery power consumption, the assigned resources (e.g., TBFs) may be maintained, while the number of timeslots that the MS monitors is reduced. This reduction in the number of timeslots being monitored can be referred to as DTR.
When operating in DTR mode an MS (for example an MS operating in packet transfer mode (i.e. with assigned packet resources)) can reduce its battery consumption by reducing the set of timeslots that the MS monitors for downlink data and/or uplink allocations (as indicated by uplink state flags (USFs)). The MS may monitor only a single timeslot or, in RTTI, a single pair of timeslots per radio block period. As a result, the network may only transmit new data or USFs on timeslots that are actually monitored by the MS. Generally, for an MS in DTR mode, the transmission or reception of any new data causes the MS to leave DTR mode. Depending upon the system implementation, other events may also cause the MS to leave DTR mode.
Although many mechanisms may be defined to cause an MS to enter DTR mode, in some network configurations two mechanisms are defined: option 1—by transmitting a PACKET UPLINK ACK/NACK (PUAN) control message containing DTR information to the MS, or option 2—by means of DTR information included within a Radio Link Control (RLC) data block transmitted to the MS.
In option 1, when a PUAN is used to instruct the MS to enter DTR, one of the conditions that should be met before the MS enters DTR is that no data block has been transmitted or received in the previous (max(BS_CV_MAX, 1)−1) block periods, where BS_CV_MAX has a pre-determined value. Generally, the condition that no data block has been transmitted or received in the previous (max(BS_CV_MAX, 1)-1) block periods must be met at the time when the PUAN is received; if not, the DTR Information in the PUAN is ignored and the MS will not enter DTR.
In the second option, when using DTR information included within an RLC data block to cause the MS to enter DTR, the conditions for the MS entering DTR are 1) that any received poll has been responded to, 2) that V(R)=V(Q), and 3) that the block with sequence number V(R)−1 contain DTR information.
In this option, the parameters V(R), V(Q), V(N) relate to the RLC receive window in the MS that is associated with RLC data blocks. V(N) refers to an array of elements, each of which can take the value INVALID or RECEIVED. V(R) identifies the block sequence number (BSN) of the next expected block (i.e. one more than the highest BSN that has been seen or, in some cases, one higher than the highest BSN whose corresponding data block has been received correctly). V(Q) refers to the lowest BSN identifying a block that has not yet been received correctly.
When using DTR information included within a RLC data block to cause the MS to enter DTR, it may not be necessary that all three conditions be satisfied in any particular order. For example, an MS may first receive blocks 1, 2, 3, and 4, then receive block 7 containing DTR information, and then later receive blocks 5 and 6 (e.g. in response to a request for retransmission). At that end of that sequence, even though all blocks were not received in order and all conditions were not satisfied in order, the MS will enter DTR because V(Q)=V(R)=8, and the block with BSN=V(R)−1 (i.e. 7) contained DTR information (presuming the MS has responded to any pending polls).
When using DTR information included within a RLC data block to cause the MS to enter DTR, Table 1 illustrates an example EGPRS downlink RLC data block for instructing an MS to enter DTR.
TABLE 1
Referring to Table 1, the carrier ID (CI) field contains an identification of the carrier that may be encoded as DTR_CI IE. The CI field can be used to indicate the carrier that the MS monitors when DTR is used. In that case, the timeslot or PDCH-pair to monitor on that carrier can be indicated with the TN/PDCH-pair field. The TN/PDCH-pair field may contain the timeslot number (BTTI configuration) or the PDCH-pair number (RTTI configuration) the MS monitors on the indicated carrier (CI field) when DTR is implemented. Finally, the DTR Blks field may indicate a subset of downlink radio blocks during which the MS monitors for USFs and/or downlink RLC data blocks when in DTR mode.
In controlling an MSs DTR state, various DTR parameters can be used to indicate which timeslot (or timeslot pair, in the case of RTTI where radio blocks are sent using two timeslots) the MS monitors when in DTR mode. The network may also indicate that the MS is to monitor these timeslots only in certain radio block periods i.e. in not all radio block periods, thus permitting the MS to save considerably more battery power.
Extended Uplink TBF (EXT_UTBF) mode allows an uplink TBF established between an MS and an associated network component to persist even when the MS has no data to transmit. Without extending the TBF, the TBF would ordinarily terminate upon successful transmission of all pending data by the MS. After terminating the TBF, if the MS subsequently needs to transmit new data, the MS and network must renegotiate the creation of a new TBF. As such, by extending the lifetime of uplink TBFs, should the MS need to transmit new data a short time after having completed a previous data transmission, the new data can be transmitted quickly using the existing TBF without the delay associated with creating a new uplink TBF.
In some cases, when in EXT_UTBF mode, the MS is required to transmit dummy data blocks (e.g., PACKET UPLINK DUMMY CONTROL BLOCKS) in response to receiving a USF indicating that the MS is allocated resources for uplink data transmission to ensure that the TBF being extended does not terminate prematurely. To prevent the unnecessary battery consumption and interference associated with transmitting dummy blocks, however, an EXT_UTBF_NODATA flag has been defined to indicate whether, with a TBF operating in EXT_UTBF mode, the MS is required to transmit the dummy blocks even if the MS has no other information to send. Generally, the network will maintain a TBF for no longer than 5 seconds after the last data has been transferred, but this limit may be extended if EXT_UTBF_NODATA is set (e.g., to a value of ‘1’).
The EXT_UTBF_NODATA flag is a 1 bit field that, when enabled, indicates the MS, during extended uplink TBF mode, may refrain from sending PACKET UPLINK DUMMY CONTROL BLOCK messages when there are no other RLC/MAC blocks ready to send in an uplink radio block allocated by the network. When refraining from sending the dummy blocks (or optionally sending dummy blocks even though not required), the MS is considered to be operating in EXT_UTBF_NODATA mode. If the flag is not enabled (e.g., has a value of 0 or is omitted e.g. because the IE in which it is transmitted is truncated or is not broadcast or otherwise transmitted at all), to maintain the uplink TBF, the MS is required to transmit a PACKET UPLINK DUMMY CONTROL BLOCK message in an uplink radio block allocated by the network when there is no other RLC/MAC block ready to send. But if the flag is enabled (e.g., has a value of 1), the MS may refrain from sending PACKET UPLINK DUMMY CONTROL BLOCK messages when there is no other RLC/MAC block ready to send in an uplink radio block allocated by the network and the uplink TBF will be maintained. Correspondingly, when an MS is operating in EXT_UTBF_NODATA mode, the network may operate in what may be considered a corresponding EXT_UTBF_NODATA mode, wherein the network may omit to increment a counter (such as counter N3101) when no RLC/MAC block is received using a radio block allocated to the MS, and hence, (or in any case,) may maintain the assigned TBF resources (i.e. may continue to consider the TBF assignment to the MS as valid) regardless of the number of radio blocks allocated to the MS for which no RLC/MAC block is received.
Generally, existing network implementations require that the broadcast indicator EXT_UTBF_NODATA be set to ‘1’ before DTR can be utilized by DTR-capable MSs. Based upon this restriction, existing network specifications limit the possible modes of operation for an MS capable of operating in EXT_UTBF_NODATA and DTR modes to the options shown in Table 2. When the EXT_UTBF_NODATA flag is not set (e.g., has a value of ‘0’), DTR is not allowed and no MSs will implement EXT_UTBF_NODATA mode. If, however, the EXT_UTBF_NODATA flag is set (e.g., has a value of ‘1’), DTR is allowed and EXT_UTBF_NODATA mode will be used by MSs (including those which do not support DTR). In other words, unless EXT_UTBF_NODATA is set, no MS are allowed to use DTR mode.
TABLE 2DTR-capableMS behaviorBroadcastNon-(duringEXT_UTBF_NODATAEXT_UTBF_NODATADTR-capablenon-DTRDTRbehavior during DTRvalueMS behaviourmode)allowed?mode000Nonot applicable111Yes1
In accordance with this system implementation, therefore, the network is forced to broadcast EXT_UTBF_NODATA=1 in order to allow any MS in the cell to use DTR. This may not be desirable if, for example, general network preferences are to limit the use of EXT_UTBF_NODATA=1 to DTR mode and/or to DTR-capable mobiles.
Other candidate implementations do not require any particular value of the EXT_UTBF_NODATA flag for a mobile to enter DTR. Implicitly, these implementations cause the MS's behavior while in DTR mode to follow the broadcast indication. In such an implementation, therefore, the possible states for MS operation are shown in Table 3.
TABLE 3DTR-capableMS behaviorBroadcastNon-(duringEXT_UTBF_NODATAEXT_UTBF_NODATADTR-capablenon-DTRDTRbehavior during DTRvalueMS behaviourmode)allowed?mode000Yes0111Yes1
This implementation, however, does not allow an MS to operate in EXT_UTBF_NODATA mode while the MS is operating in DTR mode if the EXT_UTBF_NODATA flag has a value of ‘0’. This results in the contradictory requirement that if an MS is in DTR mode to save battery power, the MS is simultaneously required to transmit dummy control blocks, wasting power.
Therefore, in existing network implementations, the network has no flexibility over EXT_UTBF_NODATA behavior if the network also wishes for MSs capable of DTR to operate in DTR mode.